Method for monitoring data processing system availability

ABSTRACT

A method, system, and product for monitoring the availability of a data processing system are proposed. The system runs a management application involving the periodic transmission of blocks of data from multiple local computers to a central computer. Whenever a block of data must be transmitted by a generic local computer, an expected transmission delay of a next block of data (with respect to the current one) is estimated and attached to the block of data. The central computer receiving the updated block of data can calculate an expected receiving time of the next block of data accordingly. If the next block of data is not received in due time, the central computer determines a failure of the local computer. The central computer also scans a subset of ports of the local computer, to ascertain whether the problem is due to a temporary unavailability of the application.

The present application is a CONTINUATION APPLICATION of applicationSer. No. 11/230,339 filed on Sep. 20, 2005.

TECHNICAL FIELD

The present invention relates to the data processing field. Morespecifically, the present invention relates to a method for monitoringavailability of a data processing system. The invention further relatesto a computer program for performing the method, and to a productembodying the program. Moreover, the invention also relates to acorresponding data processing system.

BACKGROUND ART

Monitoring the availability of a data processing system (and especiallya large network of computers) is a key issue in several applications.This activity allows detecting any unit of the system that is notworking properly, so that suitable actions can be taken in an attempt toremedy the situation. For example, it is possible to replace a crashedunit with a corresponding backup unit (previously in a standby mode), orto distribute the workload of the system across the other units (workingproperly). As a result, a high degree of fault-tolerance can beachieved, thereby avoiding any interruption in a service offered by thesystem; this is of the utmost importance in systems that implementcritical applications (for example, financial transactions, air trafficcontrol, and the like).

A commonplace solution for monitoring the availability of the system isthat of having each unit transmit a heartbeat signal at regularintervals to a central monitor. The heartbeat signal indicates that theunit is alive; therefore, if the central monitor does not receive theheartbeat signal as expected, it assumes a crash of the unit. Differentpolicies can be adopted to make the detection of the crash moreflexible; for example, this happens when a predefined number ofheartbeat signals have not been received in a significant time frame.

A drawback of the above-described technique is that it involves anoverload of the system. For example, this reduces the bandwidth of anetwork that is also used for the actual flow of data. As a result, theperformance of the applications running on the system is adverselyaffected.

A possible solution is that of reducing the transmission rate of theheartbeat signals. However, in this case the delay between any crash andits detection is accordingly increased (being equal to the heartbeatsignal period in the worst situation). The resulting degradation in theavailability of the system is unacceptable in several situations (forexample, when the system implements critical applications).

A different solution is disclosed in U.S. Pat. No. 6,370,656. Thisdocument proposes varying the heartbeat rate of each unit adaptively.For example, the heartbeat rate is updated according to the age of theunit, its temperature, or the number of errors occurred in the past. Inthis way, it is possible to have a low heartbeat rate for units that areunlikely to experience any problem; at the same time, the heartbeat rateincreases as the probability of crashes rises.

However, even this solution is not completely satisfactory. Indeed, thesystem always suffers an overload that is not negligible. Particularly,when a unit becomes too old the corresponding heartbeat rate may get sohigh to be untenable.

An additional drawback of the solutions known in the art is that theycan lead to wrong conclusions about the conditions of the differentunits. Particularly, each unit may be considered crashed even if it isworking properly; for example, this happens when an agent running on theunit is unable to transmit the heartbeat signals as required (because itis blocked or temporarily busy), when a transport infrastructure of theheartbeat signals is unavailable (for example, because of a lack ofconnection between the unit and the central monitor), and the like.

SUMMARY OF THE INVENTION

The present invention proposes a solution, which is based on the idea ofexploiting the normal flow of data for monitoring the availability ofthe system.

Particularly, an aspect of the present invention provides a method formonitoring availability of a data processing system. The system(including one or more local units and a central unit) is used forrunning an application, which involves repeated transmissions of blocksof data from the local units to the central unit. The method includesthe following steps. First of all, a block of data to be transmitted tothe central unit is provided. An expected transmission delay of a nextblock of data (with respect to the block of data) is determined. Theblock of data is then updated by attaching the indication of theexpected transmission delay. The updated block of data can now betransmitted to the central unit. At this point, the indication of theexpected transmission delay is extracted from the updated block of data.A failure of the local unit is then detected if the next block of datais not received within an expected receiving time (corresponding to theexpected transmission delay).

The proposed solution has a negligible impact on the overhead of thesystem (since it leverages the same data flow that is already used bythe application running on the system). As a result, the activity ofmonitoring the availability of the system does not adversely affect itsperformance.

At the same time, this approach provides an optimal verification ratefor each local unit; indeed, the local unit is taken into considerationonly when it is expected to transmit actual data. As a result, anyfailure of the local unit can be detected as soon as possible (withoutoverburdening the system).

The preferred embodiments of the invention described in the followingprovide additional advantages.

For example, in an embodiment of the invention the expected transmissiondelay is set according to a known transmission period of the blocks ofdata.

This approach is very simple, and it can be applied whenever theapplication involves the periodic transmission of blocks of data.

Otherwise, the expected transmission delay is estimated using apredictive algorithm (based on the actual transmission time of one ormore preceding blocks of data).

This solution is of general applicability; in any case, it ensures anacceptable degree of accuracy in many practical situations.

As a further enhancement, the expected receiving time is updated whenapproaching it (using a new expected transmission delay, which isestimated by the local computer in response to a corresponding request).

As a result, the expected receiving time is refreshed to compensate theintrinsic inaccuracy of the determination that was performed at thetransmission time of the block of data (thereby avoiding the detectionof any failure when the transmission of the next block of data is simplydelayed).

A way to further improve the solution is to have the local unit estimateand send the new expected transmission delay of its own motion (whenapproaching a corresponding expected transmission time, which is basedon an actual transmission time of the block of data and the expectedtransmission delay).

This feature avoids polling all the local units (thereby significantlyreducing the information traffic in the system).

In a specific implementation, the expected receiving time of the nextblock of data is calculated according to an actual receiving time of theblock of data and the corresponding expected transmission delay.

As a result, the expected receiving time takes into account the delay(assumed always the same for the sake of simplicity), which is requiredfor the transmission of the blocks of data from the local units to thecentral unit.

In a preferred embodiment of the invention, an attempt to contact thelocal unit is performed when the next block of data is not received indue time; the local unit is then deemed in a crashing condition only ifthe result of the attempt is negative.

This additional feature avoids reaching wrong conclusions about theconditions of the local units (for example, considering unreachable alocal unit working properly only because the central unit does notreceive the next of block of data for whatever other reason).

A suggested choice for implementing this feature is that of attemptingto connect on one or more communication ports of the local unit.

The proposed solution is very simple, but at the same time effective.

Advantageously, the expected receiving time is incremented when theresult of the above-mentioned attempt is positive; the local unit isthen deemed in a hanging condition after a predefined number ofconsecutive increments of the expected receiving time (without receivingthe next block of data).

In this way, it is possible to determine when the application isunreachable (for example, because it is blocked or a transportinfrastructure is unavailable), even if the local unit is workingproperly.

A further aspect of the present invention provides a computer programfor performing the above-described method.

A still further aspect of the invention provides a program productembodying this computer program.

Moreover, another aspect of the invention provides a corresponding dataprocessing system.

The characterizing features of the present invention are set forth inthe appended claims. The invention itself, however, as well as furtherfeatures and advantages thereof will be best understood by reference tothe following detailed description, given purely by way of anonrestrictive indication, to be read in conjunction with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a is a schematic block diagram of a data processing system inwhich the method of the invention is applicable;

FIG. 1 b shows the functional blocks of a generic computer of thesystem;

FIG. 2 depicts the main software components that can be used forpracticing the method;

FIGS. 3 a-3 b show a diagram describing the flow of activities relatingto an illustrative implementation of the method.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

With reference in particular to FIG. 1 a, a data processing system 100with distributed architecture is illustrated. The system 100 implementsan environment for managing several kinds of resources (consisting ofany logical or physical entities).

Particularly, multiple local computers 105 directly control theresources under management; a central computer 110 is responsible tomanage those resources of the system 100. The local computers 105 andthe central computer 110 communicate through a network 115 (typicallyInternet-based). An example of management system based on an autonomicmodel is described in WO-A-2004017201; in this case, the local computers105 self-adapt to a desired configuration defined by a set of rules,which are published by the central computer 110 into a sharedrepository.

As shown in FIG. 1 b, a generic computer of the system (local computeror central computer) is denoted with 150. The computer 150 is formed byseveral units that are connected in parallel to a system bus 153. Indetail, one or more microprocessors (μP) 156 control operation of thecomputer 150; a RAM 159 is directly used as a working memory by themicroprocessors 156, and a ROM 162 stores basic code for a bootstrap ofthe computer 150. Peripheral units are clustered around a local bus 165(by means of respective interfaces). Particularly, a mass memoryconsists of a hard disk 168 and a drive 171 for reading CD-ROMs 174.Moreover, the computer 150 includes input devices 177 (for example, akeyboard and a mouse), and output devices 180 (for example, a monitorand a printer). A Network Interface Card (NIC) 183 is used to connectthe computer 150 to the network. A bridge unit 186 interfaces the systembus 153 with the local bus 165. Each microprocessor 156 and the bridgeunit 186 can operate as master agents requesting an access to the systembus 153 for transmitting information. An arbiter 189 manages thegranting of the access with mutual exclusion to the system bus 153.

Moving now to FIG. 2, the main software components that can be used forpracticing the invention are denoted as a whole with the reference 200.The information (programs and data) is typically stored on the harddisks and loaded (at least partially) into the corresponding workingmemories when the programs are running. The programs are initiallyinstalled onto the hard disks from CD-ROMs.

Considering in particular a generic local computer 105, a managementagent 205 continually transmits blocks of data to the central computer110; for example, in the autonomic management system described above themanagement agent 205 periodically uploads reports relating to thecompliance of the local computer 105 with the corresponding rules.

The transmission of each block of data is intercepted by a heartbeatagent 210. The heartbeat agent 210 controls a predictor 215. Thepredictor 215 accesses a queue 220, which stores a set of samplesindicating the actual transmission times of a predefined number ofpreceding blocks of data (for example, from 10 to 20). The predictor 215estimates an expected transmission delay of a next block of data (withrespect to the current one). For this purpose, an expected transmissiontime of the next block of data is obtained by applying a LinearPredictive Filter (LPF) to the samples extracted from the queue 220; thepredictor 215 then calculates the expected transmission delay bysubtracting the current time (approximating the actual transmission timeof the block of data) from the expected transmission time. The predictor215 also determines a transmission refresh time, which is used totrigger the calculation of a new expected transmission delay of the samenext block of data; the transmission refresh time is obtained bysubtracting a value equal to a predefined percentage of the expectedtransmission delay (for example, between 5% and 10%) from the expectedtransmission time. The transmission information so obtained (i.e., theexpected transmission delay and the transmission refresh time) is savedinto a corresponding table 225, which is accessed by the heartbeat agent210.

The heartbeat agent 210 updates the block of data by attaching theexpected transmission delay. For example, the expected transmissiondelay can be inserted as a comment into a header of the block of data(in a field identified by a corresponding tag). The (updated) block ofdata is then transmitted to the central computer 110. The actualtransmission time of the block of data is also saved into the queue 220(removing the oldest value).

The above-described structure can be simplified when the managementagent 205 transmits the blocks of data to the central computer 110periodically. In this case, the expected transmission delay is set tothe transmission period of the blocks of data (with the expectedtransmission time that is calculated simply adding the period to theactual transmission time of the current block of data).

Moving now to the central computer 110, the block of data is received bya splitter 230. The splitter 230 detects the actual receiving time ofthe block of data; moreover, it extracts the expected transmission delayof the next block of data. The receiving information so obtained foreach local computer (i.e., the actual receiving time and the expectedtransmission delay) is saved into a corresponding entry of an array 235.At the same time, the splitter 230 forwards the block of data to amanagement server 240 for its processing. It should be noted that thefield including the expected transmission delay is automaticallydisregarded by the management server 240; therefore, its presence iscompletely opaque to the management server 240.

The array 235 is accessed by a processor 245, which calculates anexpected receiving time of the next block of data (for each localcomputer). For this purpose, the processor 245 increases the expectedtransmission delay by a predefined percentage (for example, between 5%and 10%); the increased expected transmission delay is then added to theactual receiving time of the current block of data. In this way, atolerance margin (for compensating the possible inaccuracy of thedetermination of the expected transmission delay) is provided. Theprocessor 245 also determines a receiving refresh time, which is used totrigger the request of a new expected transmission delay (of the nextblock of data) to the corresponding local computer, in order torecalculate its expected receiving time; the receiving refresh time issimply obtained by adding the (original) expected transmission delay tothe actual receiving time of the current block of data. The expectedreceiving time and the receiving refresh time for each local computerare saved into a corresponding entry of an array 250. The processor 245also controls a further array 255; for each local computer, the array255 stores a counter denoting the consecutive number of times for whichthe corresponding expected receiving time (in the array 250) has beenreset without receiving the respective block of data.

The arrays 250 and 255 are accessed by a heartbeat monitor 260 (whichalso interfaces with the heartbeat agent 210 of every local computerdirectly). The heartbeat monitor 260 further controls a scanner 265; thescanner 265 is used to verify the availability of a predefined subset ofcommunication ports of each local computer. As it is well known, eachport consists of a number that identifies a logical communicationchannel (so as to distinguish among multiple channels available on thesame computer). In the Internet, the ports range from 0 to 65536. Theports 1-1024 (called well-known ports) are reserved by certainprivileged services. The ports 1025-49151 (called registered ports) arepre-assigned to specific applications for use by every service. Theremaining ports 49152-65536 (called dynamic ports) can be assigned toevery service at will. The subset of ports to be verified by the scanner265 is stored in a table 270. Preferably, the subset of ports includes apredefined number (for example, between 10 and 20) of the well-knownports; an example of this subset of ports is:

20 FTP Data

21 FTP Control

23 telnet

25 SMTP

53 DNS

70 gopher

79 finger

80 HTTP (web)

88 Kerberos

110 POP3

113 AUTH

119 News

139 NETBIOS

Considering now FIGS. 3 a-3 b, the logic flow of a monitoring processaccording to an embodiment of the invention is represented with a method300. The method begins at the black start circle 303 in the swim-lane ofthe management agent of a generic local computer. A new block of data tobe transmitted to the central computer is then provided at block 306.

The transmission of the block of data is intercepted by thecorresponding heartbeat agent at block 309 (for example, using a hookingtechnique). The method then passes to block 312, wherein the expectedtransmission delay of the next block of data is estimated (eitherapplying the Linear Predictive Filter to the available samples or simplyexploiting the known transmission period); at the same time, thecorresponding transmission refresh time is calculated. The block of datais now updated by attaching the expected transmission delay so obtained(block 315). The (updated) block of data is then transmitted to thecentral computer at block 318. At the same time, the actual transmissiontime of the block of data is also saved into the corresponding queue atblock 319.

In the meanwhile, the heartbeat monitor of the central computer iswaiting in an idle loop at block 321. As soon as a new block of data isreceived from a generic local computer, the flow of activity passes toblock 324; at this point, the actual receiving time of the block of datais detected and the expected transmission delay (of the next block ofdata) is extracted. The information so obtained is saved into thecorresponding array at block 325. The block of data is then forwarded tothe management server for its processing at block 327. With referencenow to block 330, the expected receiving time of the next block of datais calculated (increasing the expected transmission delay, and thenadding the value so obtained to the actual receiving time of the currentblock of data). Descending into block 332, the corresponding resetcounter is zeroed. The method then returns to block 321 waiting for anew event.

Considering again block 321, the heartbeat monitor can be configured torefresh the expected receiving times of the local computersautomatically. In this case, when the current time reaches the receivingrefresh time of a generic local computer (i.e., it is approaching itsexpected receiving time) a refresh request is transmitted to thecorresponding heartbeat agent at block 333. In response thereto, theheartbeat agent at block 336 estimates a new expected transmission delay(with the transmission refresh time that is updated accordingly). Thisvalue is based on the actual status of the corresponding managementagent (for example, taking into account any slowdown of its operation).In addition or in alternative, the heartbeat agent can be configured torefresh the expected transmission delay of its own motion. In this case,the same block is entered when the current time reaches the transmissionrefresh time (i.e., it is approaching the expected transmission time).In any case, the method then passes to block 339, wherein the newexpected transmission delay is sent to the heartbeat monitor on thecentral computer.

The heartbeat monitor is waiting at block 342 for a response to therefreshing request (when applicable). As soon as the new expectedtransmission delay is received, the flow of activity passes to block345. In this phase, the expected receiving time of the next block ofdata is updated accordingly (recalculating it by applying theabove-described formula with the new expected transmission delay).Conversely, if the heartbeat monitor does not receive the new expectedtransmission delay within an acceptable time frame (from the sending ofthe refresh request), the flow of activity descends from block 342 toblock 348 (described in the following); the time frame is equal to apredefined percentage of the corresponding expected transmission delay(for example, between 5% and 10%).

Referring back to block 321, when the expected receiving time of ageneric local computer expires the method proceeds to block 348; in thisphase, the subset of ports to be scanned is retrieved from thecorresponding table. A loop is then performed for each port (startingfrom the first one); the loop begins at block 351 wherein a current portis verified; for this purpose, the central computer attempts to open aconnection with the local computer on that port.

If the operation succeeds (decision block 354) the method continues toblock 357; as a result, the corresponding reset counter is incrementedby one. A test is now made at block 360 to determine whether the resetcounter reaches a predefined threshold value (for example, between 2 and5). If not, the expected receiving time is reset at block 365 by addingthe corresponding expected transmission delay (with the local computerthat is still deemed alive). Conversely, a hanging condition of themanagement agent on the local computer is detected at block 366 (sinceno block of data is received irrespective of the fact that the localcomputer is working properly); a corresponding error message is thenprovided to an operator (for example, requiring a remote intervention onthe local computer for reloading the management agent). In both cases,the method then returns to the waiting block 321.

Referring back to block 354, if the attempt to open the connection onthe port fails the flow of activity passes to decision block 369. If thelast port of the subset has not been processed yet, the flow of activityreturns to block 351 for repeating the same operations on a next port.Conversely, when the verification of all the ports has failed a crashingcondition of the local computer is detected at block 372; acorresponding error message is then provided to the operator (forexample, requiring a manual intervention on the local computer for itsreboot). The method again returns to the waiting block 321.

Naturally, in order to satisfy local and specific requirements, a personskilled in the art may apply to the solution described above manymodifications and alterations. Particularly, although the presentinvention has been described with a certain degree of particularity withreference to preferred embodiment(s) thereof, it should be understoodthat various omissions, substitutions and changes in the form anddetails as well as other embodiments are possible; moreover, it isexpressly intended that specific elements and/or method steps describedin connection with any disclosed embodiment of the invention may beincorporated in any other embodiment as a general matter of designchoice.

For example, the same principles are also applicable to any otherapplication involving the repeated transmission of generic blocks ofdata (for example, a monitoring application wherein metering data isperiodically uploaded to the central computer).

Similar considerations apply if the blocks of data are updated in adifferent way; for example, the expected transmission delay may be addedby a proxy (between the local computer and the central computer), or theinformation may be inserted into a further field being added to theblock of data (which field is removed before passing the block of datato the management server). Moreover, it is possible to transmit otherinformation indicative of the delay of the next block of data (forexample, its expected transmission time); alternatively, the centralcomputer detects the failure of the local computer when the next blockof data is not received within a different expected receiving time (forexample, calculated without any tolerance margin by simply using theoriginal expected transmission delay), or this operation is performed byanother computer.

Likewise, when the application involves the periodic transmission ofblocks of data the expected transmission delay can be set in any otherway according to the corresponding period (for example, incrementing itby a predefined percentage).

On the other hand, the use of different predictive algorithms (based onthe actual transmission time of one or more preceding blocks of data) iscontemplated (for example, using filters of higher order or of theKalman type).

Similar considerations apply if the refresh of the expected transmissiondelay is triggered in a different way (in any case, in response to theapproaching of the expected receiving time on the central computerand/or of the expected transmission time on the local computer).

Moreover, the central computer can calculate the expected receiving timewith a different formula (based on the actual receiving time of thecurrent block of data and the expected transmission delay of the nextone).

Without departing from the principles of the invention, the central unitcan scan other ports of the local unit (for example, one or more dynamicports that are used by known applications); in any case, a vanilla scanof all the ports is not excluded.

The proposed solution is also suitable to be implemented incrementingthe expected receiving time by a different value when the centralcomputer succeeds in contacting the local computer (for example, by apredefined percentage of the expected transmission delay).

In any case, the programs and the corresponding data can be structuredin a different way, or additional modules or functions can be provided;moreover, the proposed solution can implement an equivalent method (forexample, with similar or additional steps).

Likewise, it is also possible to distribute the programs in any othercomputer readable medium (such as a DVD).

Similar considerations apply if the system has a different architectureor is based on equivalent units; moreover, each computer can haveanother structure or it can be replaced with any data processing entity(such as a PDA, a mobile phone, and the like).

In any case, even though in the preceding description reference has beenmade to a distributed data processing system, this is not to be intendedas a limitation; indeed, the invention can also be applied to monitorthe availability of the components of a computer (for example, whereinperipheral units repeatedly transmit blocks of data to a centralprocessor).

Moreover, it will be apparent to those skilled in the art that theadditional features providing further advantages are not essential forcarrying out the invention, and may be omitted or replaced withdifferent features.

For example, the use of the proposed solution only when the applicationinvolves the periodic transmission of blocks of data is not excluded.

Conversely, it is possible to apply the predictive algorithm to estimatethe expected transmission delay of the next blocks of data in any case.

An implementation of the proposed solution with the refresh of theexpected receiving time that is controlled only by the central computeror only by the local computers is within the scope of the invention. Inany case, there is nothing to prevent an implementation of the inventionwithout any refreshing procedure.

It is also possible to determine the expected receiving time of the nextblock of data in a different way (for example, simply setting it to avalue that is provided by the local computer together with the currentblock of data).

Moreover, the reference to the scan of the ports must not to beinterpreted in a limitative manner; indeed, in different embodiments ofthe invention it is also possible to verify the local unit attempting toconnect with it in a different way (for example, requesting a specificservice).

Likewise, other actions can be taken when the above-mentioned attemptsucceeds (for example, always considering the local computer alivewithout using any reset counter, or providing a warning to the operatorinforming that the local computer is a candidate for failing).

In any case, an implementation of the present invention without any portscan (or more generally any attempt to connect with the local unit) whenthe next block of data is not received in due time is contemplated.

Vice-versa, it should be noted that this additional feature is suitableto be used (alone or in combination with the other features of theinvention) even in a standard method of monitoring the availability ofthe system (i.e., based on the heartbeat signals).

Alternatively, the programs are pre-loaded onto the hard disks, are sentto the computers through the network, are broadcast, or more generallyare provided in any other form directly loadable into the workingmemories of the computers.

However, the method according to the present invention leads itself tobe carried out with a hardware structure (for example, integrated inchips of semiconductor material), or with a combination of software andhardware.

1. A method for monitoring availability of a data processing system,including at least one local unit and a central unit, for running anapplication involving repeated transmissions of blocks of data from theat least one local unit to the central unit, wherein for each local unitthe method includes the steps of: providing a block of data to betransmitted to the central unit; determining expected transmission delayof a next block of data with respect to the block of data; updating theblock of data by attaching an indication of the expected transmissiondelay; transmitting the updated block of data to the central unit, theupdated block of data providing the indication of the expectedtransmission delay such that not receiving the next block of data withinan expected receiving time corresponding to the expected transmissiondelay causes a detection of a failure of the local unit; receiving arefresh request to the local unit in response to an approaching of theexpected receiving time; determining an indication of a new expectedtransmission delay of the next block of data in response to the refreshrequest; and transmitting the indication of the new expectedtransmission delay from the local unit to the central unit, the newexpected transmission delay providing a basis for an update for theexpected receiving time.
 2. The method according to claim 1, furtherincluding the steps of: determining an indication of a new expectedtransmission delay of the next block of data in response to anapproaching of a corresponding expected transmission time based on anactual transmission time of the block of data and the expectedtransmission delay; and transmitting the indication of the new expectedtransmission delay from the local unit to the central unit, the newexpected transmission delay providing an update for the expectedreceiving time.
 3. The method according to claim 1, wherein the step ofdetection of the failure of the local unit includes: incrementing theexpected receiving time of the next block of data in response to apositive result of the attempt to connect; and determining a hangingcondition of the application on the local unit in response to apredefined number of consecutive increments of the expected receivingtime without receiving the next block of data.
 4. A computer usableprogram product comprising a computer usable storage device includingcomputer usable code for monitoring availability of a data processingsystem, including at least one local unit and a central unit, forrunning an application involving repeated transmissions of blocks ofdata from the at least one local unit to the central unit, wherein foreach local unit the computer usable code comprising: computer usablecode for providing a block of data to be transmitted to the centralunit; computer usable code for determining expected transmission delayof a next block of data with respect to the block of data; computerusable code for updating the block of data by attaching the indicationof the expected transmission delay; computer usable code fortransmitting the updated block of data to the central unit; computerusable code for extracting the indication of the expected transmissiondelay from the updated block of data; computer usable code for detectinga failure of the local unit if the next block of data is not receivedwithin an expected receiving time corresponding to the expectedtransmission delay; computer usable code for sending a refresh requestto the local unit in response to an approaching of the expectedreceiving time; computer usable code for the local unit determining anindication of a new expected transmission delay of the next block ofdata in response to the refresh request; computer usable code fortransmitting the indication of the new expected transmission delay fromthe local unit to the central unit; and computer usable code forupdating the expected receiving time according to the new expectedtransmission delay.
 5. The computer usable program product according toclaim 4, further including: computer usable code for the local unitdetermining an indication of a new expected transmission delay of thenext block of data in response to an approaching of a correspondingexpected transmission time based on an actual transmission time of theblock of data and the expected transmission delay; computer usable codefor transmitting the indication of the new expected transmission delayfrom the local unit to the central unit; and computer usable code forupdating the expected receiving time according to the new expectedtransmission delay.
 6. The computer usable program product according toclaim 4, wherein the computer usable code for detecting the failure ofthe local unit further includes: computer usable code for incrementingthe expected receiving time of the next block of data in response to apositive result of the attempt to connect; and computer usable code fordetermining a hanging condition of the application on the local unit inresponse to a predefined number of consecutive increments of theexpected receiving time without receiving the next block of data.
 7. Adata processing system for monitoring availability of a data processingsystem, including at least one local unit and a central unit, forrunning an application involving repeated transmissions of blocks ofdata from the at least one local unit to the central unit, the dataprocessing system comprising: a storage device including a storagemedium, wherein the storage device stores computer usable program code;and a processor, wherein the processor executes the computer usableprogram code, and wherein for each local unit the computer usableprogram code comprises: computer usable code for providing a block ofdata to be transmitted to the central unit; computer usable code fordetermining expected transmission delay of a next block of data withrespect to the block of data; computer usable code for updating theblock of data by attaching the indication of the expected transmissiondelay; computer usable code for transmitting the updated block of datato the central unit; computer usable code for extracting the indicationof the expected transmission delay from the updated block of data;computer usable code for detecting a failure of the local unit if thenext block of data is not received within an expected receiving timecorresponding to the expected transmission delay; computer usable codefor sending a refresh request to the local unit in response to anapproaching of the expected receiving time; computer usable code for thelocal unit determining an indication of a new expected transmissiondelay of the next block of data in response to the refresh request;computer usable code for transmitting the indication of the new expectedtransmission delay from the local unit to the central unit; and computerusable code for updating the expected receiving time according to thenew expected transmission delay.
 8. The data processing system accordingto claim 7, further including: computer usable code for the local unitdetermining an indication of a new expected transmission delay of thenext block of data in response to an approaching of a correspondingexpected transmission time based on an actual transmission time of theblock of data and the expected transmission delay; computer usable codefor transmitting the indication of the new expected transmission delayfrom the local unit to the central unit; and computer usable code forupdating the expected receiving time according to the new expectedtransmission delay.
 9. The data processing system according to claim 7,wherein the computer usable code for detecting the failure of the localunit further includes: computer usable code for incrementing theexpected receiving time of the next block of data in response to apositive result of the attempt to connect; and computer usable code fordetermining a hanging condition of the application on the local unit inresponse to a predefined number of consecutive increments of theexpected receiving time without receiving the next block of data.